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DEVELOPMENT  OF  THE  “CITY  OF  QUALITY  (COQ)”  GROUP 
DECISION  SUPPORT  SYSTEM 

L  INTRODUCTION 

In  March  1988,  memorandum  30452  was  sent  from  the  office  of  the  Secretary  of 
Defense  stating  that  “It  is  critical  at  this  time  that  the  Department  of  Defense  ...  focus  on 
quality  as  the  vehicle  for  achieving  higher  levels  of  performance.”  A  number  of  Air  Force 
efforts  are  currently  being  directed  toward  this  Total  Quality  Management  (TQM).  One 
important  facet  of  these  efforts  is  their  need  for  group  technology;  many  aspects  of  systems 
being  developed  for  the  Air  Force  must  be  considered  by  many  different  decision  makers. 

In  particular,  the  Air  Force  wants  to  include  reliability,  maintainability  and  other 
“ilities”  in  the  design  phase  of  projects,  rather  than  addressing  these  issues  after  production. 

In  order  to  do  this,  group  decision  support  tools  are  needed  to  allow  decision  makers 
to  assess  trade-offs  and  to  communicate  their  expertise  among  themselves. 

Both  a  mathematical  theory  of  multi-person  multi-objective  decision  making,  and 
working  software  are  needed  for  this  effort.  For  some  time,  the  Japanese  have  had  success 
using  a  mathematical  model  by  Taguchi  for  computing  optimal  system  specifications.  More 
recently,  a  promising  technique  in  use  at  Mutsubishi’s  Kobe  shipyards  was  described  by 
Hauser  and  Clausing.  This  technique  is  a  very  promising  approach  for  capturing  the 
parameters  needed  by  the  Taguchi  model.  An  integration  of  these  two  approaches  into  a 
software  package  that  automates  the  mechanical  details  would  be  of  great  practical  benefit  to 
the  Air  Force. 

II.  OBJECTIVES  OF  THE  RESEARCH  EFFORT 

My  objective  for  the  summer’s  research  was  the  study  of  group  decision  support  aids 
for  Concurrent  Engineering  (CE). 

I  initially  performed  an  extensive  review  of  relevant  literature,  both  journal  articles 
and  relevant  reports, with  a  goal  of  developing  a  system  to  support  multi-person,  multi¬ 
attribute  decision  making  (MPMADM)  in  support  of  Quality  Function  Deployment  (QFD) 
and  CE.  The  review  of  MPMADM  included  a  taxonomy  of  such  systems  and  the 
mathematical  theory  underlying  them.  I  next  reviewed  articles  and  reports  on  concurrent 
engineering  and  quality,  including  English  descriptions  of  the  Taguchi  model,  the  theory  of 
(Deming,  1986),  and  techniques  for  developing  Hypertext  prototypes. 
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To  actually  implement  the  system,  I  began  by  outlining  the  mathematical  theory  of 
MPMADM.  The  specific  version  chosen  for  the  implementation  was  the  team  approach.  The 
specific  formulation  of  the  MPMADM  problem  is  based  strongly  on  the  Taguchi  model,  as 
described  in  (Elmaghraby  et  al.,  1986).  The  “House  of  Quality”  paradigm  as  described  in 
(Hauser  and  Clausing,  1988)  was  then  chosen  as  the  framework  to  acquire  the  parameters 
required  by  the  Taguchi  model. 

In  order  to  implement  the  “House  of  Quality,”  I  investigated  Hypertext  as  a  potential 
software  vehicle.  Using  Hypertext,  I  designed  a  linked  ensemble  of  “Houses  of  Quality,” 
leading  to  a  tool  best  described  as  a  “City  of  Quality  (Coq)”,  a  tool  that  allows  the  decision 
makers  to  communicate  their  concerns  among  themselves,  that  provides  a  record  of  decisions 
made  and  rationales  behind  those  decisions,  that  encourages  quantification  of  goals  and 
objectives,  and  that  encourages  hierarchical  decision  making. 

I  next  implemented  a  very  preliminary  Hypertext  prototype  of  the  system  as  a  “Proof 
of  Concept,”  and  as  a  guide  to  the  sorts  of  systems  which  might  be  most  useful  to  Air  Force 
decision  makers.  This  prototype  is  a  model  “City  of  Quality”  (Coq)  system  which  consists  of  a 
linked  series  of  “Houses  of  Quality.” 

HI.  MULTI-PERSON  MULTI-ATTRIBUTE  DECISION  MAKING  (MPMADM) 

Difficulties  in  MPMADM 

Multi-person  multi-attribute  decision  making  (MPMADM)  is  the  problem  with  which 
real-world  decision  makers  are  faced.  Mathematically,  the  problem  may  be  represented  a& 
an  n-person  game  in  which  the  decision  makers  are  to  solve  the  following  problem: 

min  L(x,9)  (3.1) 

x 

S.T.  x  e  a 

The  vector  x  is  the  decision  vector,  to  be  set  by  the  several  decision  makers  acting 
in  conjunction;  the  vector  6  is  a  random  vector,  called  the  state  of  nature;  the  set  O  is  the 
technology  set  of  feasible  decisions;  L(x,8)  is  the  (possibly  non-linear)  loss  function,  which, 
for  this  problem,  is  a  matrix  of  losses,  with  L^x.G)  the  loss  of  attribute  j  incurred  by  decision 
maker  i.  See  Fig.  3.1. 
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Figure  3.1  Game  for  Group  Decision  Making _ 

Note  that,  for  this  general  forui  of  the  game,  any  decision  maker  may  potentially 
influence  any  component  of  the  decision  vector.  This  is  the  basic  game  theoretic  formulation, 
as  in  (Luce  and  Raiffa,  1957) 

In  addition,  not  shown  in  Figure  3.1,  is  an  information  function  £(0).  £j(0)  is  the 
information  available  to  decision  maker  i.  One  of  the  decision  variables  available  to  each 
decision  maker  is  the  possibility  of  communicating  £i(0)  to  one  or  more  other  decision  makers. 
The  loss  function  includes  the  costs  of  this  communication. 

The  problem  (3.1)  is  usually  approached  by  attacking  each  of  its  constituent  parts; 
unfortunately,  not  only  are  all  the  parts,  in  general,  intractable,  our  goal  is  solution  of  the 
overall  problem. 

To  summarize  the  difficulties  encountered  in  trying  to  solve  equation  (3.1)  observe: 

1)  the  equation  does  not  really  make  sense,  even  for  a  single  decision  maker, 
if  each  Lj  (x,  9)  is  a  vector:  there  is  ordering  on  9?n,  n £2,  which  is  consistent  with 
the  ur,ual  topology,  hence  no  single  methodology  for  multi-attribute  decision  making 
can  be  a  prescriptive  standard; 


2)  even  if  every  decision  maker  were  to  have  a  scalar  loss  function  of  some 
sort,  if  these  functions  are  all  different,  there  is,  by  Arrow's  Impossibility  Theorem 
(Arrow,  19631),  no  logically  consistent  method  to  combine  them  into  a  group  decision, 
except  under  special  circumstances; 

3)  if  the  group  somehow  settles  on  a  scalar  group  loss  function,  l(x,9),  there  is 
no  agreement  on  optimal  methods  for  dealing  with  uncertainty; 

4)  if,  finally,  the  group  agrees  on  a  deterministic  scalar  loss  function,  (e.g. 
expected  value  <Kx)  =  E(l(x,9))  this  is,  in  general,  non-linear  and  non-convex,  and  the 
set  £2  is,  in  general,  a  non-convex  mixed  integer  domain,  so  the  resultant  optimization 
problem: 

min  <J)(x)  (3.1a) 

x 

S  .  T  .  x  €  Q 

has  no  efficient  means  of  (exact)  solution.  In  the  absence  of  some  rather  strong 
assumptions  which  enable  the  problems  1 — 4  to  be  circumvented,  a  system  to  support  the 
various  aspects  of  group  decision  making  may  not  be  programmed  to  provide  a  general 
solution  algorithm  for  MPMADM,  but  will,  rather,  be  an  information  and  decision  support 
system,  making  the  cost  of  communication  (including  intertemporal  communication)  as  low 
as  possible,  and  providing  access  to  as  many  of  the  available  individual  decision  support  tools 
as  possible. 

Overview  of  general  solution  approaches  to  MPMADM 
In  the  absence  of  good,  canonical  methods  for  solving  the  problems  (1) — (4)  above,  a 
large  number  of  approaches  have  been  proposed.  These  may  be  summarized  as  follows: 

(1)  Multi-attribute  decision  making.  Disregarding  9  for  now,  assume  that  L={L(x))  is 
the  set  of  all  multi-attribute  losses  available  to  a  single  decision  maker.  A  multi-attribute 
loss  is  represented  as  a  vector  in  ordinary  Euclidean  space  9In,  i.e.,  it  is  assumed  that  each 
attribute  may  be  individually  quantified.  In  addition,  assume  that  the  decision  maker  has 
some  rational  preference  ordering  on  L  c  Then  the  following  holds: 


1  Arrow  actually  refers  to  this  as  the  Possibility  Theorem.  Modem  usage,  however,  refer  to  the  theorem 
as  either  the  Impossibility  Theorem,  or  as  the  Dictator  Theorem. 
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Proposition  1.  If  L  is  a  countable  ordered  set,  then  there  is  an 
order-preserving  mapping 


O ;  L — >Q.  (3.2) 

where  Q,  is  the  rational  numbers. 

For  n>2,  9?n  is  a  topological  vector  space,  but  Q,is  an  ordered  field,  and  it  is  tempting 
(though  not  justified  by  decision  theory)  to  use  those  field  properties.  In  addition,  <t>  is 
usually  extended  from  L  to  9ln-  The  simplest  method  of  doing  this  is  the  usual  linear  multi¬ 
attribute  utility  theory.  A  vector  of  parameters  ne  iRn  is  statistically  estimated  such  that 

rcTl  =  d>(l)  VleL  (3.3) 

induces  the  correct  ordering  on  L.  Unfortunately,  if  I  L  |  >  n,  (3.3)  is  overdetermined,  and, 

has  no  solution,  except  in  a  least-squares  sense.  In  general,  such  a  solution  will  not  agree 
with  the  decision  maker’s  original  ordering  only  for  a  subset  of  L.  A  non-linear  variation 
uses  the  decision-makers  preferences  for  hypothetical  lotteries  to  fit  a  smooth  curve  or 
piecewise  linear  function  to  <I>.  In  (Currim  and  Sarin,  1984)  efforts  along  these  lines  led  to  a 
linear  <t>  that  fit  63%  of  decisions  made,  and  to  a  non-linear  <t>  that  fit  80%  of  the  decisions, 
but  in  no  case  were  they  able  to  find  a  functional  form  for  O  that  fit  all  decisions  with  any 
positive  degrees  of  freedom. 

One  may  accept  as  a  solution  a  choice  of  C>  that  covers  “most”  of  L,  or  claim  that  (3.3) 
(or  a  non-linear  variation)  is  a  prescriptive  model  for  multi-attribute  decision  making. 

A  less  controversial  approach  is  that  of  Pareto-optimality.  This  imposes  the  natural 
partial  order  on  9tn: 


x  5 y  if xj  £ yj  V i  (3.4) 

x  <y  if  x  £y  andx  *y  . 

then  a  point  le  L  is  non-Pareto  optimal  with  respect  to  minimization  if 

3l'6L3  1'<1  (3.5) 

A  point  is  Pareto  optimal  if  it  is  not  non-Pareto  optimal.  Basically,  a  point  is  Pareto 
optimal  if  no  feasible  point  can  reduce  the  loss  associated  with  one  attribute  without 
increasing  the  loss  associated  with  another  attribute.  The  drawback  to  Pareto  optimality  is 
that  many  non-equivalent  points  will  generally  be  Pareto  optimal,  and  the  theory  of  Pareto 
optimality  offers  no  method  for  choosing  between  Pareto  optimal  points.  Work  by  Storbeck 
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(oral  communication)  indicates  that  decision  makers  may  not  even  eliminate  from 
consideration  points  that  are  not  Pareto  optimal,  judging  the  lack  of  optimality  to  reflect 
noisy  data,  rather  than  actual  inferiority. 

However,  any  information  system  to  support  multi-attribute  decision  making  must , 
at  an  absolute  minimum,  inform  the  decision  makers  about  the  Pareto-optimality  of  solutions 
under  consideration. 

(2)  Group  decision  making.  A  first  simplification  which  partially  circumvents  Arrow’s 
theorem  is  to  reduce  from  the  group  decision  making  problem  to  the  distributed  decision 
making  problem,  in  which  each  decision  maker  has  complete  control  over  some  of  the 
decision  variables,  as  in  Figure  3.2. 

Arrow’s  theorem  does  not  apply,  since  each  decision  maker  is  allowed  to  select  a 
preference  for  the  value  of  some  decision  variables  independent  of  the  choices  of  the  other 
decision  makers.  Unfortunately,  game  theory  has  examples  of  multi-person  games  with  no 
reasonable  notion  of  solution,  so  a  further  simplification  is  commonly  made  to  team 
decision  making  in  which  there  is  a  single  loss  function  for  all  players,  as  in  Figure  3.3. 
This  is  the  case  studied  in,  for  example,  (Marschak  and  Radner,  1972). 

Each  player  i  in  this  game  has  access  to  an  information  function  £j(0)  and  may 
signal,  or  communicate  £j(0)  to  team  members  j^i  at  some  cost  Xij,  which  is  included  in  the 
loss  function.  This  signalling  is  explicitly  indicated  in  the  figure. 

One  method  of  improving  the  expected  value  of  the  loss  function  is  to  reduce  the  cost 
of  communication,  which  is  the  goal  of  Coq. 

(3)  Uncertainty.  The  random  vector  9  may  represent  risk,  the  situation  where  0  has  a 
known  distribution  (or  at  least  a  known  expected  value  E(0)  and  variance  matrix  Var(0))  or  it 
may  represent  uncertainty,  where  the  distribution  is  unknown.  Since  the  mean  and 
variance  represent  two  independent  attributes  (assuming  all  other  moments  may  be 
disregarded  in  the  analysis),  this  represents  a  return  to  multi-attribute  decision  making.  The 
methods  most  commonly  used  here  are  similar  to  (1)  except  that  the  function  <b  is  either 
expected  utility,  or,  as  a  further  simplification,  expected  value,  in  the  case  of  risk.  A 
further  refinement  proposed  by  (Chames  and  Cooper,  1961)  is  to  minimize  the  expected 
value  of  the  loss,  subject  to  a  (set  of)  constraints  which  proscribe  unacceptably  large  losses: 

min  E(L(x)) 

x 

S.T.  P(L(x))  5  b)  5  e  (3.6) 
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This  is  called  chance-constrained  programming  in  (Charnes  and  Cooper,  1961). 

The  traditional  method  for  dealing  with  uncertainty,  as  opposed  to  risk,  is  to  impose 
some  distribution,  usually,  in  the  case  of  complete  uncertainty,  a  uniform  prior,  or,  where 
some  information  is  available,  the  maximum  entropy  prior. 

(4)  Non-linear  optimization.  Given  the  assumptions  that  must  be  made  for  (1) — (3)  a 
form  for  the  resultant  objective  functional  E(d>(L(x,8)))  may  be  selected  in  such  a  way  that 
the  optimization  is  amenable  to  whatever  solution  procedures  are  on  hand,  whether  they  be 
heuristic  or  algorithmic,  numerical  or  symbolic. 


IV.  TEAM  BASED  MPMADM  WITH  MODIFIED  TAGUCHI  LOSS 

FUNCTIONS 

Based  on  (1) — (4)  above,  it  is  necessary  to  develop  appropriate  L  and  d>  for  QFD.  For 
the  sake  of  notation  consistent  with  the  literature,  introduce  the  production  process. 
Decision  makers  are  given  a  decision  vector  s,  which  may  also  be  interpreted  as  input  to  the 
production  process.  The  process  then  produces  quantifiable  outputs 

x  =  p(s,e)  (4.1) 

where  e  is  a  random  vector,  xe  <Kn  is  a  random  vector,  se  is  determined  by  the 
decision  makers  in  a  way  that  minimizes  the  loss  L(x,0)  associated  with  x  and  the  random 
state  of  the  world,  0.  In  general,  unfortunately,  producers  do  not  know  p  except  for  some  set 
Sc9!n  (often  a  small,  finite  set).  This  is  an  impediment  to  minimizing  L(x,0). 
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For  non-profit  agencies,  the  usual  notation  of  maximizing  a  profit  function  does  not 
make  sense.  The  non-profit  agency  would  seem  more  like  a  consumer,  maximizing  mission 
effectiveness  subject  to  a  budget  constraint,  solving  the  problem 

max  Ef f (x)  (4.2) 

s 

S.T.  C ( 8 )  <  B 

Assuming  Efffx)  to  be  an  isotonic  function  of  B,  (4.2)  is  equivalent  to 

max  Eff (x)  (4.2') 

8 

S.T.  C ( 8 )  =  B 

This  becomes  a  problem  when  distributed  decision  making  is  used.  Here  (4.2)  is  hierarchi¬ 
cally  decomposed  into  a  series  of  subproblems,  with  subvectors  SjeiRni  of  s  and  (Bj)3^Bj=B. 

i 

The  coordinator’s  problem  is  then 

max  Eff  (x)  (4.3a) 

(Bi) 

while  the  subordinates’  problems  are 

max  Eff  (Xj_) 

»i 

S.T.  C (s)  =  Bi  (4.3b) 

where  x^  p  |  ^  (si,e|). 

Exact  solution  of  (4.3)  would  lead  to  a  good  global  solution;  however,  while  solution  of 
problem  (4.3b)  is  often  straightforward,  solution  of  (4.3a)  is  usually  quite  difficult  in  which 
case  the  solutions  to  (4.3b)  may  lead  to  erroneous  results.  A  more  robust  formulation  of  the 
non-profit  producers’  problem  is  given  by: 

min  Cp(s)  +  Cc  (x)  (4.4) 

8 

where  Cp(s)  is  the  producer’s  cost  of  selecting  the  decision  variables  s  and  Cc(x)  is  the  con¬ 
sumers’  cost  associated  with  production  of  output  x.  Taguchi’s  first  contribution  is  the  notion 
that  a  producer  should  minimize  total  cost  to  the  organization  (or  nation)  rather  than  maxi¬ 
mizing  its  own  profit.  In  his  original  formulation,  as  described  in  (Elmaghraby  et  al.,  1986), 
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however,  Taguchi  omitted  the  producer’s  cost.  Equation  (4.4)  has  been  called  the  extended 
Taguchi  cost  function  in  (Tse  and  Cralley,  1988). 

In  addition  to  the  general  form  (4.4),  Taguchi  also  specified  the  specific  form  to  be 
used  for  Cc(x):  the  consumer  is  presumed  to  have  a  target  x  for  x.  Then 

Cc  (x)  =  ^Wifxi-Ti)2  (4.5) 

i 

where  w  is  a  vector  of  weights  to  be  applied  to  the  deviations.  The  scalar  loss  function  is 
then 


L (s)  =  Cp (s)  +  E(Cc(x) ) 


(4.6) 


=  Cp(a)  +  wtct2+wt(  x-t))  (4.7) 

where  x  is  the  mean  of  x  and  ct2  is  the  variance  of  x. 

This  formulation  is  particularly  felicitous,  as  it  is  readily  amenable  to  distributing 
the  decision  processes  among  the  team:  beginning  with  the  final  consumer’s  requirements  xo, 
the  producer  may  establish  a  decision  vector  si  that  minimizes  (4.6).  The  components  of  si 
may  then  require  production,  so  the  process  is  repeated  with  si  in  place  of  x  and  82  in  place 
of  s.  The  global  nature  of  (4.6)  ensures  that,  if  each  sub-problem  is  solved  to  minimize  L(sj) 
the  resulting  solution  will  be  optimal.  In  addition,  the  formulation  is  unconstrained.  Thus, 
this  approach  is  also  recommended  by  (Ross,  1988). 

Depending  on  available  software  and  on  the  nature  of  the  problem,  the  simple  form 
(4.5)  may  be  modified  without  affecting  the  main  thrust  of  the  analysis.  One  may  use,  for 
example,  a  piecewise  quadratic  rather  than  a  simple  quadratic  function,  absolute  values 
rather  than  quadratics,  or  the  satisficing  formulation  as  described  by  (Chames  and  Cooper, 
1961)  rather  than  an  optimizing  formulation. 

We  assume  that  Cp(s)  is  readily  available:  i.e.,  that  for  any  choice  of  the  decision 
variable  s,  the  costs  of  production  are  known.  The  team  information  function  is  described  by 
the  estimates  each  of  the  team  members  has  for  e,  0,  x,  p,  and  w,  ej,  $j,  Xj,  pi  and  wj.  The 
assumption  that  this  is  a  team  decision  problem  implies  that  all  members  of  the  team  share 
the  scalar  loss  function  (4.6)  and  the  function  of  the  GDSS  is  to  obtain  the  best  possible  group 
estimates  for  e,  8  ,  x,  and  w  based  on  the  individual  estimates,  i.e.,  the  GDSS  provides  a 
group  function 


_  ,  A  A  A  A  A  A  A  A  A  A  ^ 

G:  (Ei;  0j.;  Xj.;  pi;  Wj.)(s)-»(e;  9;  X;  p;  w  )  (s)  VaeQ  (4.7) 
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which  takes  the  matrix  of  individual  estimates  and  computes  the  group  estimate.  An  optimal 
group  function  may  be  obtained  as  a  consequence  of: 


Proposition  2.  Let  y  be  a  random  vector,  y±  a  matrix  of  estimates 

A 

of  y,  and  Ej=y  -  yi  a  matrix  of  random  errors.  If  the  Ejare  unbi- 

A 

ased,  then  y,  the  minimum  variance  unbiased  linear  group  estimate 
of  y  is 


A 

y 


Var"1  (Ej)yi 
Var"1  (£j) 


(4.8) 


As  discussed  in  (Pyeatt  and  Wolfe,  1989)  this  solves  the  problem  of  reconciling  expert 
judgements  from  a  panel  of  experts,  even  when  the  experts’  answers  are  correlated.  It  does 
not,  however,  solve  the  problem  of  expert  bias,  which  is  a  matter  for  further  research. 

Application  of  Proposition  2  requires  that  we  obtain  an  estimate  of  Var*1^)  based  on 
prior  decisions  and  results.  Hence  the  system  must  maintain  such  a  database. 


V.  CITY  OF  QUALITY  TEMPLATE  FOR  GDSS 
The  framework  selected  for  collecting  the  data  identified  in  §4  is  based  on  the  model 
observed  at  Mitsubishi  and  described  by  (Hauser  and  Clausing,  1988).  The  original  work 
requires  the  decision  makers  responsible  for  design,  development,  and  production  of  a  system 
to  fill  out  four  “Houses  of  Quality.”  Our  extension  automates  the  links  between  the  four 
houses,  to  produce  an  integrated  system  we  call  the  City  of  Quality  (Coq).  The  Coq: 

1)  Assists  decision  makers  to  establish  all  requirements.  In  the  notation  of  §4,  Coq 
reduces  the  chance  that  an  important  target,  Tj,  in  (4.5)  above  is  omitted — i.e.,  given 
an  incorrect  weight  wj  =  0;  this  is  listed  as  a  serious  problem  in  (De  Vera  and  others, 
1988) 

2)  Provides  a  framework  for  setting  formal  weights  and  targets,  rather  than  leaving 
the  decision  process  fuzzy  and  intuitive; 

3)  Maintains  a  record  of  how  trade-offs  were  resolved; 

4)  Reduces  the  probability  that  a  customer  requirement  fails  to  be  addressed  in  the 
final  design. 

The  system  that  does  this  is  shown  in  Figure  5.1,  which  shows  the  basic  House.  The 
left  side  of  the  house,  labeled  “Customer  Attributes,”  contains  the  customer  requirements;  a 
column  is  provided  for  their  relative  weights.  It  is  designed  to  encourage  a  hierarchical 
approach  to  the  requirement  definition,  which  will  be  discussed  further  below.  The  “attic” 
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(just  below  the  roof)  labeled  “Engineering  Characteristics”  in  conjunction  with  the  bottom  of 
the  house  is  used  to  list  quantitative,  engineering  specifications,  target  values,  importance, 
estimated  difficulty  and  costs.  Also  provided  are  spaces  for  comparison  with  existing  designs. 


_  _  Figure  5. 1  The  House  of  Quali 


The  central  portion  of  the  house  provides  space  to  indicate  which  engineering 
specifications  address  (or  degrade)  a  customer  requirement  The  roof  indicates  the  synergies 
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and  conflicts  among  the  engineering  specifications.  Finally,  a  graph  on  the  right  hand  side  of  • 
the  House  indicates  competitive  position. 

This  decomposes  the  group  decision  problem  into  the  various  cognitive  parts,  and 
provides  the  support  for  ( 1) — (4)  above. 


The  design  of  the  Coq  system  is  intended  to  facilitate  the  difficult  problem  of  trade-off 
analysis. 

Minimizing  the  loss  function  (4.6)  is  complicated  by  the  fact  that  the  production 

dxj 

function  p:9ln->Xc;9lm  may  not  be  onto;  in  particular,  it  is  possible  that  xeX.  In  addition,  ^77 
dxk 

may  be  related  to  -^77,  in  such  a  way  that  selection  of  s  to  improve  target  x;  degrades  target 

Xfc.  Selection  of  that  value  of  s  which  minimizes  (4.6)  must  thus  be  done  either  informally  or 
formally.  Support  for  formalizing  the  decision  process  is  supported  by  (Keeney  and  von 
Winterfeldt,  1989)  and  this  is  provided  by  the  central  matrix  of  the  House  and  by  the  roof  of 
the  house. 


For  example,  in  (Garvin,  1987)  eight  primary  customer  requirements  are  identified 
for  all  systems:  1)  Performance;  2)  Features;  3)  Reliability;  4)  Conformance;  5)  Durability;  6) 
Serviceability;  7)  Esthetics;  and  8)  Perceived  quality.  A  technical  specification  that 
addresses  one  of  these  will  tend  to  degrade  one  or  more  of  the  others,  as  very  high 
performance  items  have  a  (justifiable)  reputation  for  reduced  reliability  and  durability. 

We  emphasize  that  all  decision  makers,  with  or  without  a  decision  support  system, 
must  make  these  trade-offs,  consciously  or  unconsciously.  Within  our  framework,  ignoring 
reliability  in  favor  of  performance  consists  of  putting  a  preemptive  weight  wj  on  the 
performance  characteristic.  The  Coq  system  allows  this  choice  on  the  part  of  the  decision 
maker,  but  makes  it  explicit. 

It  will  also  be  the  case  that  the  engineering  specifications  may  exhibit  synergy  or 
antagonism,  and  this  is  explicitly  indicated  on  the  roof  of  the  House.  Taking  this  synergy 
into  account  may  result  in  significant  cost  savings,  while  explicitly  acknowledging  the 
antagonistic  factors  may  prevent  an  unanticipated  product  failure. 

This  basic  support  for  explicit  trade-off  analysis  is  the  model  from  Mitsubishi 
described  by  Hauser  and  Clausing.  What  Coq  provides  is  access  to  sophisticated  decision 
support  and  modeling  tools  to  facilitate  the  process. 

Since  Coq  is  a  very  low  cost  system,  it  is  available  to  a  wide  range  of  decision  makers 
who  may  formerly  have  had  no  access  to  GDSS  software,  and  who  may  not  be  familiar  with 
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the  concept  of  trade-off  analysis.  Hence  an  interface  is  provided  to  provide  a  great  deal  of 
support  to  the  decision  makers. 

Communication  is  facilitated  by  the  fact  that  users  of  Coq  are  prompted  for  relative 
weights,  for  indications  of  which  customer  attributes  are  addressed  or  degraded  by  which 
technical  specification,  and  for  the  synergies  and  antagonisms  among  the  technical 
specifications.  The  user  may  specify  these  relationships  in  a  form  tailored  to  the  user’s 
cognitive  mode,  and  the  system  will  then  display  the  results  in  a  common  form,  for  the 
benefit  of  other  group  members. 

Where  simple  models  and  formulae  are  appropriate  (e.g.  unit  conversions)  or  where  a 
database  of  physical  constants  is  needed,  the  software  provides  “slots”  where  these  may  be 
inserted.  Complex  models  developed  in  FORTRAN  or  other  conventional  languages  are  also 
completely  accessible.  The  calculations  needed  by  designers  are  not  only  available  from 
within  Coq,  they  become  part  of  the  House,  and  hence  may  be  reviewed  by  other  members  of 
the  group. 

Intertemporal  Communication  Support 

In  development  of  a  large,  complex  system,  the  design  process  is  spread  out  over  a 
period  of  months,  or,  more  often,  years.  Many  of  the  decision  makers  responsible  for 
production  and  maintenance  at  the  end  of  this  process  will  have  had  little  or  no  contact  with 
the  decision  makers  responsible  for  the  initial  statement  of  need  and  preliminary  design. 
While  the  original  Hauser  and  Clausing  article  indicated  that  this  could  be  done  with  linked 
Houses,  as  shown  in  Figure  5.2,  their  design  left  a  lot  of  tedious  details  to  be  addressed  by 
manual,  paper  methods.  Coq  is  designed  to  automate  these  details,  and  to  provide  additional 
functionality  as  well. 

Coq  is  designed  for  any  decomposition  of  the  system  life  cycle  into  phases,  although 
for  illustration  the  stages  suggested  by  (Hauser  and  Clausing,  1988)  are  used.  At  each 
interface,  data  from  the  previous  stage  are  automatically  transferred  to  the  next  stage;  in 
addition,  as  each  requirement  at  stage  i  is  addressed  by  a  technical  specification,  this 
information  is  relayed  back  through  the  previous  stages.  The  result  is  a  system  that  ensures 
that  some  specification  addresses  each  customer  requirement.  The  original  system 
suggested  that  this  could  be  done  manually;  in  practice,  large  systems  might  have  hundreds 
of  requirements,  and  it  is  unlikely  that  decision  makers  would  take  sufficient  care  in 
checking  each  row  for  an  indication  that  the  requirement  is  addressed;  however,  this 
guarantee  may  be  programmed  into  a  suitable  software  package  which  can  produce  an 
exception  report  and  bring  the  failing  to  the  immediate  attention  of  the  decision  maker. 
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Figure  5.2  Linked  Houses  form  the  City  of  Quality 

From  a  more  theoretical  perspective,  provided  that  the  decision  space  S  is  compact, 
the  formulation  of  the  loss  function  (4.6)  is  a  real  valued  function,  and  hence  must  have  a 
global  minimum,  i.e.,  there  is  a  “right  answer”  to  the  problem  as  stated.  In  fact,  there  are  two 
“right  answers:”  the  answer  that  minimizes  expected  loss,  given  the  limited  information  at 
the  time  the  decision  is  taken,  and  the  answer  that  minimizes  actual  loss  if  the  random 
factors  e  and  9,  the  production  function  p,  the  optimal  targets  x  and  the  appropriate  weights 
wj  for  each  target  xj  be  known.  Rational  decision  makers  will  always  take  the  decision  that 
minimizes  the  expected  loss  of  (4.6);  when  this  differs  from  the  posterior  optimal  solution,  the 
error  is  due  to  erroneous  estimation  of  one  of  these  five  vectors.  From  Proposition  2,  this 
estimate  may  be  optimized  if  the  system  has  an  estimate  of  the  variance  of  the  error  of  the 
estimates  made  by  the  decision  makers.  In  order  to  estimate  this  variance  accurately,  a 
record  must  be  kept  of  prior  decisions  and  results. 

This  has  tended  not  to  happen  (Hill,  Duffy,  oral  communication).  It  is  not  possible  for 
an  information  system  to  enforce  usage;  however,  Coq  is  designed  to  be  as  user  friendly  as 
possible,  to  encourage  decision  makers  to  record  decisions,  rationales  for  those  decisions,  and 
the  engineering  level  formulae  that  support  those  derisions. 

VI.  HYPERTEXT 

Overview  of  Hypertext 

The  concept  of  hypertext  is  credited  to  Vannevar  Bush,  while  the  word  is  credited  to 
Ted  Nelson  by  (Smith  and  Weiss,  1988)  and  by  (Vaughan,  1988).  Pure  hypertext  is  a  non* 
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linear  form  of  writing.  Ordinary  written  documents  may  be  visualized  as  a  linear  graph  as 
in  Figure  6.1.  Hypertext,  on  the  other  hand,  allows  an  arbitrary  network  as  in  Figure  6.2. 
Topologically  speaking,  the  linear  graph  of  ordinary  text  can  be  embedded  in  one  dimensional 
space,  while  the  network  of  hypertext  requires  at  least  two  dimensions,  and  possibly  three. 


Start  Finish 

_ Figure  6. 1  Linear  writing.  _ 


Each  node  in  the  network  represents  some  text,  and  is,  perhaps,  best  visualized  as  a 
page  in  an  encyclopedia  or  instruction  manual.  The  reader,  given  a  book  or  other  paper 
document,  is  forced  to  move  sequentially  through  the  text,  with  random  access  tedious,  and 
the  time  required  for  such  access  interrupting  the  reader’s  train  of  thought. 


The  horizontal  dimension  represents  breadth;  the  vertical  dimension  represents 
detail.  Arcs  connect  related  nodes.  A  straight  horizontal  arc  indicates  a  simple  narrative;  for 
example,  the  four  nodes  at  A  connected  by  three  straight  horizontal  arcs  might  represent  four 
pages  in  an  article.  If  two  nodes  at  the  same  vertical  level  are  connected  by  a  straight 
horizontal  arc  from  node  i  to  node  j,  node  i  is  called  a  predecessor  of  node  j,  while  node  j  is 
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called  a  successor  of  node  i.  If  a  node  has  a  successor,  this  is  the  default  link  at  the  node: 
this  is  the  natural  path  if  the  user  does  not  need  additional  detailed  information,  and  does 
not  wish  to  follow  up  on  cross-references.  There  can  be  only  one  successor  arc  from  each 
node,  as  is  obvious  from  the  (Euclidean)  geometry,  since  only  one  straight  line  arc  may 
extend  directly  to  the  right  from  a  given  node. 

The  straight  line  arcs  directed  diagonally  downward  depict  the  hierarchy  of 
information:  lower  nodes  represent  details  about  higher  nodes.  For  example,  at  B  in  the 
Figure,  there  are  no  successor  arcs,  and  hence  no  narratives  continued  across  nodes.  The 
reader  may  peruse  deeper  regarding  a  subject,  but  there  is  no  direct  connection  between  the 
nodes  at  a  level. 

As  is  usual  in  network  terminology,  if  node  i  at  a  higher  level  is  connected  to  node  j  at 
a  lower  level,  node  i  is  called  a  parent  of  node  j,  while  node  j  is  called  a  child  of  node  i. 

Caution.  For  persons  familiar  with  network  and  hierarchical  databases,  this 
is  not  the  same  network  structure:  nodes  are  not  so  much  entities  (in  the  sense  of 
network  databases)  but  pages  of  text,  and  the  parent/child  relation  here  is  unrelated 
to  the  formal  parent/child  relation  between  data  items  in  the  network  and 
hierarchical  data  models. 

Unlike  successors,  a  node  may  have  any  number  of  children,  as  the  information  on  a 
single  page  might  have  a  number  of  details  (in  regular  text,  footnotes.) 

Finally,  the  curved  arcs  represent  relationships  between  nodes  that  are  more 
serendipitous  than  that  of  predecessor/successor  or  parent/child,  and  indicate  cross- 
references  that  might  occur.  These  are  called  sibling  arcs,  whether  they  connect  nodes  on 
the  same  level  or  different  levels,  since  depth  in  different  branches  of  the  network  (measured 
as  distance  from  the  root  node)  is  not  really  comparable.  Nodes  connected  by  sibling  arcs  are 
called  siblings.  Again,  a  node  may  have  many  siblings,  as  a  page  of  text  may  have  many 
cross-references.  Sibling  arcs,  unlike  parent/child  arcs,  are  usually  bi-directional. 

As  in  normal  network  terminology,  a  node  with  no  children,  siblings  or  successors  is 
called  a  leaf  node.  A  node  to  which  only  leaf  nodes  are  attached  is  a  twig  node. 

All  nodes  and  arcs  are  created  by  the  author  of  the  hypertext  document.  For  the 
reader,  access  to  a  node  is  primarily  limited  to  traversing  a  connected  path  to  that  node.  On 
opening  a  hypertext  document,  the  reader  is  placed  at  the  root  node,  and  may  proceed  along 
any  available  arc.  The  canonical  term  for  reading  a  hypertext  document  is  browsing.  The 
arcs  are  directed,  and  it  is  not  possible  to  traverse  an  arc  backward;  however,  it  is  possible  to 
back  up,  i.e.,  to  retrace  a  path  already  traversed.  The  distinction  is  clear  when  a  node  has 
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multiple  parents:  one  mayback  up  to  the  parenL  via  which  the  node  was  accessed,  but  may 
not  access  any  other  parent  directly. 

In  some  implementations,  the  reader  may  have  access  to  a  search  command  which 
allows  direct  access  to  the  next  node  in  the  document  (or  possibly  all  nodes)  satisfying  the 
reader’s  search  criterion.  Access  to  the  search  function  may  be  under  the  author’s  control, 
and  may  be  present  at  some  nodes,  absent  at  others,  depending  on  how  structured  the  author 
wishes  the  exposition  of  the  document  to  be.  The  most  common  implementation  of  this 
search  function  is  a  simple  string  search,  although  a  few  implementations  of  hypertext 
provide  sophisticated  search  facilities.  The  arcs  explicitly  established  by  the  author  are 
called  hard  links;  additional  soft  links  are  created  when  the  user  does  a  search,  as 
hypertext  remember  the  paths  taken,  and  allows  them  to  be  retraced. 

The  advantage  to  hypertext  is  that  !t  is  almost  as  easy  to  follow  the  parent/child  arcs 
and  sibling  arcs  as  it  is  to  follow  the  normal  successor  path,  making  it  possible  to  readily 
proceed  at  the  desired  level  of  detail,  to  check  any  of  the  cross-references  provided  by  the 
author,  and,  by  using  the  string  searching  feature,  to  check  other  cross-references  that  occur 
to  the  user  while  browsing  the  document. 

In  its  pure  form,  however,  hypertext  does  not  provide  facilities  for  communication  of 
data  between  nodes:  this  requires  the  more  advanced  product,  hypermedia. 

Hypermedia 

While  Bush  probably  envisioned  pure  hypertext,  the  storage  of  information  on 
electronic  media  encourages  much  more  creative  methods  for  communicating  that 
information.  At  a  minimum,  graphics  are  added  if  the  hardware  supports  them;  at  the  same 
conceptual  level,  digitized  sound  may  be  played  at  a  node.  This  introduces  a  second  network 
structure,  an  inheritance  net,  which  is  independent  of  the  hypertext  network.  In 
displaying  information,  identical  (or  very  similar)  graphics  and  sounds  may  be  mixed  with 
different  text  in  displaying  information  to  the  end  user.  Rather  than  re-creating  the  shared 
graphical/sound  resources,  a  node  may  inherit  these  resources  from  another  node.  Again,  if 
an  inheritance  arc  exists  between  node  i  and  node  j,  we  call  node  i  a  parent  and  node  j  a 
child. 

The  hypermedia  concept  is  not,  however,  limited  to  static  text  and  graphics.  In  its 
most  general  form,  each  node  may  be  a  complete  program,  which  executes  when  the  node  is 
accessed.  Many  implementations  of  hypertext/hypermedia  include  a  programming  language. 
Nodes  in  which  the  underlying  program  is  written  in  this  “native”  programming  language 
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may  be  general  nodes;  if  the  program  is  an  external  program,  the  node  it  represents  must  be 
a  leaf  node. 

In  this  general  form,  hypermedia  is  an  underlying  structure  connecting  available 
electronic  resources  in  whatever  manner  the  author  feels  is  most  suitable  for  the 
presentation  of  information.  Nodes  could  include  CAD/CAM  programs,  animations, 
explanations,  etc. 

The  limitation  of  pure  hypertext  mentioned  above,  that  data  cannot  be  transmitted 
between  nodes,  does  not  apply  when  each  node  is  a  program,  which  may  store  and  retrieve 
data  from  shared  resources  either  in  core  memory  or  from  secondary  storage  facilities. 

The  HyperCard®  Implementation  of  Hypertext:  Capabilities  and  Limitations 

Because  HyperCard  was  the  first  mass  produced  and  readily  available 
implementation  of  hypertext,  is  is  often  mistakenly  assumed  that  Hypercard=Hypertext. 
Hypertext  had,  in  fact,  been  implemented  in  prototypical  forms  on  workstations  for  many 
years  before  HyperCard  appeared,  and  is  currently  available  in  many  forms  on  many 
platforms.  HyperCard  is  merely  the  most  accessible  implementation  available  at  this  time. 

In  HyperCard,  each  node  is  displayed  as  a  card  the  size  of  a  Macintosh  Plus  screen;  on 
other  platforms,  the  same  black  and  white  card  is  displayed.  In  addition  to  ordinary  text, 
support  is  provided  for  bitmapped  graphics,  sound,  arithmetic  operations,  and  simple 
programming.  A  simple  inheritance  structure  is  also  provided:  cards  (nodes)  with  common 
graphical  features  and  placement  of  text  share  a  common  background,  from  which  they 
inherit  these  common  features.  Support  for  more  complex  inheritance  schemes  is  only 
provided  by  the  recursive  programming  language,  which  allows  authors  to  implement  such 
inheritance  for  themselves.  No  support  is  provided  for  vector  graphics  or  color. 

For  use  in  a  group  setting,  it  is  desirable  for  users  to  be  able  to  add  comments  to 
nodes  in  a  way  that  limits  accidental  interference,  a  feature  called  non-disruptive 
annotation  in  (Akscyn,  McCracken,  and  Yoder,  1988)  who  observe  that  this  is  an  important 
part  of  their  system2.  Again,  this  may  be  programmed  by  the  author  of  a  HyperCard  docu¬ 
ment,  but  is  not  provided  as  part  of  the  standard  system. 

In  actual  implementations,  there  is  a  physical  design  as  well  as  a  logical  design.  In 
HyperCard,  a  physical  file  containing  one  or  more  cards  (and  one  or  more  backgrounds)  is 
called  a  stack.  In  terms  of  performance,  switching  to  a  stack  not  recently  accessed  is  rela- 

2Their  system  was  originally  called  ZOG,  but  the  engine,  separated  from  the  specifics  of  the  original 
application,  is  now  a  general  purpose  hypertext  engine  called  KMS. 
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tively  time  consuming.  In  addition,  the  search  function,  mentioned  earlier,  is  designed  to 
search  on  a  single  stack.  Access  to  this  function  is  controlled  by  the  author;  however,  should 
the  author  wish  to  give  the  reader  the  ability  to  search  over  several  separate  stacks,  each 
search  must  be  provided  separately. 

Standard  HyperCard  provides  limited  facilities  for  use  over  a  LAN;  however,  these 
facilities  may  be  purchased  separately  by  members  of  Apple’s  development  group,  APDA. 
Existing  tools  are  limited  to  stack  locking,  rather  than  card  locking.  An  ideal  system  would 
allow  two  or  more  users  to  simultaneously  view  a  card  and  attach  comments,  but  this  does 
not  seem  possible  with  HyperCard  at  this  time,  so  sequential  multi-user  access  will  be 
required.  In  addition,  the  system  designer  must  make  the  trade-off  between  the  greater 
multi-user  accessibility  of  a  system  with  many  small  stacks  vs.  the  enhanced  performance  of 
a  system  with  a  few  large  stacks. 

The  facilities  are  also  primitive  in  the  area  of  security.  Security  issues  in  a  multi¬ 
user  database  include  security  from  inadvertent  damage  to  other  users’  data,  and  deliberate 
damage  to  other  users’  data.  Protection  from  the  latter  is  especially  difficult.  The 
HyperCard  programming  language  makes  sophisticated  security  programming  possible,  but, 
again,  programming  is  necessary,  as  security  features  are  not  built  into  the  program.3 

One  feature  present  in  HyperCard  which  does  provide  excellent  security,  however,  is 
the  Oracle®  interface.  This  enables  a  HyperCard  user  to  store  all  (sensitive)  data  on  an 
Oracle  database  either  on  the  HyperCard  platform  machine,  or  on  a  mainframe  computer, 
with  all  the  security  thereby  available.  By  having  cards  that  contain  no  data  of  their  own,  but 
merely  access  it  from  a  multi-user  mainframe,  some  of  the  other  multi-user  problems  can  be 
circumvented,  but  this  requires  programming  the  access  sequence  to  the  mainframe,  as  well 
as  mainframe  database  programming. 

The  final  limitation  of  HyperCard  is  performance.  Given  the  low-end  platform 
available  and  the  fact  that  it  is  an  interpreted  language,  access  to  large  databases  with 
complex  programs  executing  at  each  node  can  result  in  unacceptable  response  times.  This 
does  not,  however,  reduce  its  appeal  for  prototyping,  and  as  a  terminal  vehicle  for  moderate 
sized  data  bases  with  only  simple  processing  at  most  nodes. 


3A  prompt  for  passwords  and  a  simple  encryption  scheme  are  provided,  but  the  steps  to  be  taken  after 
prompting  and  receiving  either  a  valid  or  invalid  password  must  be  programmed  by  the  author. 
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Design  methodology  for  Hypertext 

Rapid  prototyping  Development  of  any  information  system  involves  user  interface 
issues  and  data  processing  issues.  Experience  shows  that  the  former  tend  to  be  more  difficult 
and  as  important  as  the  latter,  but  tend  to  be  grossly  underweighted  in  the  initial  design 
process.  All  the  problems  in  systems  life  cycle  that  this  (and  related  software  systems)  are 
intended  to  address  are,  in  fact,  present  in  the  life  cycle  of  the  software  system  itself.  With 
traditional  life  cycle  methodologies,  decisions  made  early  in  the  design  cycle,  when  designers 
are  faced  with  the  greatest  uncertainty  about  the  system,  have  the  greatest  impact  on  the 
cost  and  usability  of  the  system. 

The  key  problem,  called  the  “Feigenbaum  Bottleneck”  in  (Michie,  1983)  and  (Duke, 
Nijssen,  and  Twine,  1988)  is  the  production  of  a  formal  specification  of  the  problem  which 
corresponds  with  the  users’  needs.  Initially,  users  and  system  designers  often  have  difficulty 
communicating  just  what  those  needs  are,  and  the  prototype  has  been  found  to  be  an  effective 
medium  for  this  communication.  The  idea  is  to  produce  a  working  version  of  the  product 
using  a  very  high  level  language,  one  that  facilitates  modifications  and  rapid  development  of 
user  interfaces.  This  prototype  may  evolve  into  a  production  product;  more  often,  the 
performance  limitations  of  the  very  high  level  language  make  the  prototype  unacceptable  in 
a  production  mode.  In  the  latter  case,  the  prototype  forms  a  formal  specification  for  the 
production  version — the  user  “signs  off”  on  the  prototype,  and  the  desired  appearance  and 
functionality  of  the  production  system  are  now  clearly  established.  All  that  remains  is  to 
implement  the  system  in  a  high  performance,  perhaps  more  portable  version. 

Design  standards  for  Hypertext.  Various  organizations  have  proposed  standards  for 
structured  software  development.  Few  apply  to  hypertext  projects.  In  typical  hypertext 
projects,  data  flow  and  program  flow  diagrams  are  meaningless:  the  data  do  not  flow,  nor 
does  the  program.  The  hypertext  document  is  static,  with  the  dynamics  supplied  by  the  user. 
Even  a  paper  user’s  manual  would  largely  re-create  the  information  in  the  hypertext 
document,  but  in  a  less  accessible  format. 

Of  the  hypertext  projects  reported  to  date  in  the  open  literature,  none  have  provided 
design  standards/methodologies  comparable  to  those  established  for  other  software  projects. 
While  much  research  remains  to  be  done  in  this  area,  a  few  points  have  been  established. 

1)  Supporting  documents  for  a  hypertext  project  include: 

a)  the  logical  layout,  showing  the  nodes  and  arcs; 

b)  the  inheritance  structure  chart  of  the  nodes; 

c)  the  physical  layout  of  the  nodes  on  the  various  storage  media  used; 


21 


d)  conventional  documentation  for  any  programs  which  execute  at  the  nodes 
(omitted  if  the  nodes  are  just  text,  no  program;) 

2)  The  structured  design  process  should  include: 

Before  any  actual  programming 

a)  preparing  the  logical  layout  chart; 

b)  preparing  the  inheritance  structure  chart,  to  minimize  redundan¬ 
cies; 

c)  preparing  conventional  documentation,  if  appropriate; 

d)  review  of  the  above  documents; 

Followed  by 

e)  implementation  of  the  preliminary  prototype; 

f)  preparation  of  the  physical  layout  chart; 

g)  refinement  (go  to  a)). 

3)  The  implementation  process  should  have  controls  that  ensure  uniformity  at  each 

node,  so  that  the  identical  symbols  produce  parallel  effects. 

The  following  conventions  were  chosen  for  the  logical  structure  chart,  in  addition  to 
the  basic  conventions  of  successor  arcs,  parent/child  arcs,  and  sibling  arcs  described  earlier: 
initially,  the  tentative,  preliminary  name  of  every  node  (and  brief  description,  if  not  clear 
from  the  name)  is  filled  in  using  an  italic  font.  As  a  node  is  implemented,  the  italics  are 
replaced  with  roman  type.  Important  nodes  are  indicated  with  boldface  type.  This  way,  the 
structure  chart  also  serves  as  a  dynamic  project  management  tool. 

The  reserved  word  “Local”  is  used  to  indicate  nodes  that  serve  to  support  another 
node,  “Help”  nodes,  for  example,  and  the  facility  that  allows  a  reader  to  attach  comments  to 
the  node.  A  structure  chart  following  these  conventions  will  be  displayed  in  a  later  section. 

Svnergv  between  Hypertext  and  Coa  template.  The  basic  idea  of  a  Coq,  as  shown  in 
Figure  5.2,  suggest  some  sort  of  network.  From  the  root,  an  image  derived  from  Figure  5.2, 
the  network  branches  to  the  four  houses.  Less  obvious  is  that  the  basic  House  of  Quality 
shown  in  Figure  5.1  has  a  hierarchical  decomposition,  well  suited  to  a  network:  this  is  the 
decomposition  discussed  in  §5,  into 

1)  customer  attributes,  weights,  etc; 

2)  technical  specifications,  cost,  importance,  etc.; 

3)  the  matrix  indicating  which  specifications  address  which  requirement,  and  to  what 

extent; 

4)  the  roof  indicating  trade-offs  between  the  various  technical  specifications. 


In  addition,  there  is  interest  in  encouraging  a  hierarchical  approach  to  the 
acquisition  of  customer  attributes  and  technical  specifications,  and  this  is  particularly 
appropriate  to  the  hypertext  network:  a  node  is  assigned  for  customer  attributes.  This  has, 
as  children,  primary  attributes.  These  children  have,  as  their  children,  nodes  for  secondary 
attributes,  etc. 

Beyond  this  is  the  ability  to  attach  notes  and  comments  to  any  part  of  a  house.  The 
intersection  of  the  row  for  an  attribute  and  the  column  for  a  specification  forms  a  node.  This 
node  has,  as  children,  separate  nodes  corresponding  to  each  of  the  decision  makers  in  the 
group  responsible  for  the  design.  This  nodes  then  have  as  children  nodes  with  formulae  used 
to  establish  the  specification  from  the  attribute  and  with  comments  from  the  decision  makers 
explaining  their  rationale  for  trade-offs  made.  This  sort  of  network,  operating  interactively, 
is  “readily”  implemented  in  hypertext,  but  with  difficulty  using  conventional  programming. 

VII.  PRELIMINARY  DESIGN  OF  THE  COQ  HYPERTEXT  SYSTEM 

Description  of  the  Design 

The  first  step  in  the  design  of  a  Hypertext  system  is  establishment  of  the  logical 
layout  chart,  described  in  §4.  The  root  node  of  any  HyperCard  document  is  called  “Home”  and 
provides  access  to  a  variety  of  applications.  These  could  have  been  deleted;  however,  Coq 
tries  to  keep  as  many  tools  and  facilities  as  possible  to  encourage  decision  makers  to  use  the 
system  and  avoid  the  “weak  link”  problem  where  one  key  decision  maker  does  not  use  the 
GDSS  and  renders  the  entire  system  ineffective.  The  root  to  the  Coq  tree  is  Figure  5.2. 
Overall,  the  top  level  of  the  tree  looks  like  Figure  7.1: 


The  four  non-local  children  of  the  City  of  Quality  node  all  look  like  Figure  5.1  when 
accessed  (except  for  titles).  They  function  in  similar  ways,  with  one  important  exception:  in 
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the  basic  house,  much  of  the  task  to  be  accomplished  is  the  acquisition  of  customer 
attributes,  while  in  the  other  houses  (parts,  process,  production)  the  left  hand  side  is 
automatically  filled  in  by  the  system  with  the  information  from  the  previous  house.  The 
structure  for  these  houses  is  shown  in  Figure  7.2. 

The  most  complex  structure,  however,  is  the  initial  House  of  Quality,  because  this 

must: 

1)  Acquire  the  customers’  attributes,  which  are  somewhat  vague,  and  more  qualita¬ 
tive  than  quantitative;  then 

2)  Translate  these  into  formal,  quantitative,  engineering-level  specifications. 

Later  houses  must  do  the  more  structured  process  of  translating  formal  specifications 
from  one  arena  to  another,  which  is  much  easier  than  the  unstructured  (or  semi-structured 
at  best)  process  of  translating  informal  requirements  into  technical  specifications.  The  top- 
level  logical  structure  of  the  House  is  shown  in  Figure  7.3. 


Figure  7.2  Logical  Structure  for  Parts  Deployment  Subnet 


Figure  7.3  Top-Level  Logical  Structure  for  House  of  Quality 


The  subsystem  for  acquisition  of  customer  requirements  is  a  separate,  almost  stand¬ 
alone  module  for  GDSS.  It  is  designed  to  implement  the  first  stage  of  multi-attribute 
decision  making,  by  acquiring  the  matrix  of  required  attributes  and  weights  for  each  decision 
maker  involved.  This  matrix  may  then  be  used  in  any  number  of  models:  the  system  has  a 
very  open  architecture  that  allows  co-ordinators  to  select  any  of  the  pre-installed  linear 
options,  or  to  add  options  of  their  own. 

The  logical  structure  chart  for  this  subsystem  is  complicated  by  the  fact  that  it  is 
dynamic.  This  is  a  new  concept  in  Hypertext:  the  development  of  Coq  involves  basic 
research,  and  new  information  technologies  are  being  developed.  Initially,  the  node  for 
acquiring  the  customer  attributes  is  a  twig  node  (its  only  subnode  being  the  local  node  with 
help  information).  The  node  has  the  appearance  shown  in  Figure  7.4. 


Figure  7.4  First  Screen  for  Acquiring  Customer  Attributes 
This  card  (node)  has  certain  features  common  to  all  cards:  clicking  on  the  arrow  in 
the  lower  right  hand  corner  returns  control  to  the  parent  of  the  current  card;  clicking  on  the 
little  houses  return  to  the  root  node;  help,  of  course,  is  available  by  clicking  on  the  lower  left 
hand  button.  As  explained  at  the  help  node,  the  user  is  to  select  one  of  the  eight  slots.  This 
is  intended  to  encourage  a  hierarchical  decomposition  of  the  customer  attributes:  it  is  easy  to 
define  up  to  8  primary  attributes.  Each  of  these  may  be  readily  decomposed  into  8  secondary 
attributes,  etc.  With  effort,  users  may  circumvent  the  8  attribute  limit,  but  the  hierarchical 
approach  with  no  more  than  8  primary  attribute  and  no  more  than  8  sub-attributes  for  each 
attribute  is  easier  for  the  user  to  define  than  a  flat  approach  with  many  attributes  or  sub¬ 
attributes  at  the  same  level. 

When  an  empty  slot  is  selected,  the  system  creates  a  new  node  (card).  A  hard  link  is 
established  between  the  slot  and  the  new  node,  and  selecting  that  slot  again  allows  editing 


the  attribute.  The  node  for  defining/editing  the  attribute  currently  has  the  appearance 


shown  in  Figure  7.5. 
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Figure  7.5  Card  to  Acquire  a  Specific  Requirement 

This  card,  created  as  needed,  illustrates  a  few  of  the  GDSS  features  of  Coq.  The  non- 
disruptive  annotation  feature  is  provided  by  the  “Attach  Comment”  command  (called  a 
button  in  HyperCard).  Each  user  is  allowed  to  attach  one  or  more  comments.  Features  for 
editing  comments,  for  viewing  other  users’  comments,  etc.  are  possible. 

The  second  GDSS  feature  is  the  History.  A  record  is  kept  of  every  modification  and 
the  person  responsible  for  the  modification. 

The  downward  pointing  arrow  at  the  bottom  of  the  screen,  the  first  time  it  is 
activated,  adds  a  node  like  Figure  7.4.  to  the  network,  and  creates  a  hard  link  to  the  node 
(thereby  re-defining  the  function  of  the  arrow  from  a  create  function  to  a  transition  function.) 
The  result  is  an  innovative  use  of  self-modifying  software,  but  one  in  which  the  self- 
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modifications  are  carefully  controlled.  The  new  card  (Figure  7.4)  will  have  the  customer 
requirement  of  Figure  7.5  printed  vertically  in  the  box  on  the  left-hand  side,  and  the  user  will 
then  be  able  to  add  secondary  requirements.  As  each  secondary  requirement  is  added,  a  new 
card  like  Figure  7.5  will  be  created  and  hard  linked  to  the  overview  of  secondary 
requirements  associated  with  its  primary  requirement. 

Note,  finally,  that  this  process  is  recursive,  and  is  limited  only  by  the  storage  capacity 
of  the  secondary  storage  medium:  the  hierarchy  may  be  easily  extended  to  an  arbitrary 
depth.  After  the  system  has  been  used,  the  structure  chart  might  look  like  Figure  7.6. 


The  process  for  acquiring  technical  specifications  is  similar,  although  somewhat 
different  information  is  appropriate  for  technical  specifications,  as  shown  in  Figure  7.7.  In 
particular,  quantitative  targets,  cost,  and  technical  difficulty  are  acquired,  in  addition  to 
relative  importance.  If  used  in  a  competitive  situation,  estimated  values  for  competitors  may 
be  acquired  and  stored  as  well.  Again,  self-modifying  software  and  recursion  are  used  to 
make  the  “knowledge  acquisition”  process  as  painless  as  possible  for  the  user. 
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Figure  7.7  Node  for  Acquiring  Technical  Specifications _ 

Vm.  SUMMARY 

The  basic  mathematical  theory  of  multi-person  multi-attribute  decision  making 
developed  in  this  paper  shows  the  applicability  of  the  Taguchi  formalism.  This  formalism 
lends  itself  to  the  House  of  Quality  paradigm  for  “knowledge  acquisition”  of  the  parameters 
that  are  required  by  the  formalism.  Finally,  the  process  of  turning  qualitative  user 
requirements  into  a  functional  system  that  addresses  those  requirements  is  not  only 
amenable  to  automation,  but  requires  automation  in  order  to  minimize  the  costs  of  the 
communications,  including  intertemporal  communications,  among  the  responsible  decision 
makers. 

This  automation  and  communication  are  achieved  by  the  City  of  Quality,  or  Coq 
system,  developed  using  Hypertext  methods.  Innovative  informatics  involving  self-modifying 
software  were  developed.  The  result  is  a  powerful  platform  for  group  decision  support  of 
total  quality  and  unified  life-cycle  engineering. 

As  a  side  benefit,  for  purposes  of  management  of  this  (and  future)  hypertext  projects, 
rough  guidelines  were  established  for  hypertext  projects,  guidelines  that  can  be  extended  as 
hypertext  becomes  an  increasingly  important  tool  for  software  development  and  prototyping. 


DC  RECOMMENDATIONS 

The  design  of  the  Coq  system  has  been  described;  implementation  has  been  started, 
but  is  not  yet  complete.  In  developing  Coq,  it  was  discovered  that  hypertext,  originally 
intended  to  allow  an  author  to  prepare  a  static  but  multi-dimensional  document,  is  awkward 
for  linking  data  between  different  parts  of  the  document.  Currently,  this  is  addressed  by 
building  complex  data  structures;  however,  this  solution  has  an  adverse  impact  on 
maintainability  of  the  system. 

A  second  limitation  of  the  implementation  of  hypertext  used  is  based  on  the 
expectation  of  either  limited  user  input,  or  input  by  a  sophisticated  user;  hence,  the  platform 
has  no  provision  for  error  trapping.  As  an  example  of  the  impact  of  this  omission,  should  the 
user  not  understand  that  a  numerical  weight  is  needed,  and  instead  provide  a  verbal 
description  (or  make  a  typo)  the  error  will  not  be  detected  until  a  calculation  is  made  with 
the  data.  The  error  will  break  out  of  Coq  and  into  native  HyperCard,  where  the  user  must 
figure  out  what  to  do.  Since  the  error  message  may  be  delivered  long  after  the  error  was 
made,  this  could  prove  very  frustrating  for  the  novice  or  casual  user. 

Partial  solutions  include  developing  an  algorithm  for  distinguishing  between  valid 
numbers  and  non-numeric  data,  or  performing  an  immediate  calculation,  so  at  least  the  error 
message  (perhaps  uninformative)  will  be  more  closely  related  to  the  action  which  produced  it. 

A  major  extension  planned  that  will  address  both  these  limitations  is  to  link  all  cards 
to  a  relational  database,  which  will  make  data  transfer  relatively  painless,  as  well  as 
providing  better  security  and  integrity. 

In  its  current  form,  the  system  is  limited  to  sequential  multi-user  access.  This 
limitation  is  partly  the  result  of  the  current  hardware  platform,  which  is  a  stand-alone 
machine,  and  partly  the  result  of  limitations  on  the  time  available  for  system  development. 
The  system  can  be  upgraded  to  concurrent  access  once  a  LAN  platform  and  additional 
software  tools  become  available. 

In  developing  the  system,  a  good  start  was  made  at  developing  project  management 
tools  for  Hypertext  projects.  These  need  further  testing  and  development  to  form  a  solid 
foundation  for  structured  development  of  Hypertext. 

The  most  important  direction  for  further  research,  however,  is  to  actually  field  test 
the  system:  this  will  conclusively  identify  deficiencies,  strengths  and  potentials. 
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